IBIS Macromodel Task Group Meeting date: 01 September 2020 Members (asterisk for those attending): Achronix Semiconductor * Hansel Dsilva ANSYS: * Curtis Clark * Wei-hsing Huang Cadence Design Systems: Ambrish Varma Ken Willis * Jared James Google: * Zhiping Yang Intel: * Michael Mirmak Keysight Technologies: Fangyi Rao * Radek Biernacki Ming Yan Todd Bermensolo * Rui Yang Marvell Steve Parker Mentor, A Siemens Business: * Arpad Muranyi Micron Technology: * Randy Wolff * Justin Butterfield SiSoft (Mathworks): * Walter Katz Mike LaBonte Teraspeed Labs: * Bob Ross Zuken USA: Lance Wang The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - Arpad asked if topic #7 (DDR5 DQ Write BCI protocol) could now be removed from the agenda. Walter said it could and that he would reintroduce the topic later when he has more to discuss. ------------- Review of ARs: - Walter to prepare a draft of a BIRD relaxing the one-to-one pin to buffer requirement. - Done, sent to the ATM and Interconnect lists. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the August 25 meeting. Michael moved to approve the minutes. Randy seconded the motion. There were no objections. ------------- New Discussion: Support for RDL in IBIS: Walter shared the latest draft of BIRD_Dup_signal_name. He said it is really a clarification BIRD, and it would involve a small change in ibischk parser logic. He said it's a question of how the tool should interpret it when 2 [Pin]s use the same signal_name. As a test, Walter had created an IBIS file with a [Pin] table containing two pins that specified the same signal_name and different [Model] names. He noted that the ibischk parser issued no errors, but what should an EDA tool do in this case? Walter said the fact that two pins with the same signal_name could have different model names was really confusing, and his new BIRD made it explicit that this was an error. Having resolved that issue, how does one interpret 2 pins having the same signal_name? Walter said that 20 years ago there had been a few IBIS models that used the same signal_name for every data line, but that was not done in IBIS [Component]s anymore. He noted that it makes more sense to say such pins are connected, and that this is the approach they are taking with EMD (BIRD202). Arpad commented on the historical aspect. He noted that up until recently, EMD for example, signal_name had been meaningless in terms of the simulation. We had only stated that it should be the data book signal name. Only the [Pin] name and [Model] name were actively affecting the simulation, and signal_name was merely informative. Now, with IBIS 7.0 Interconnect Model syntax (BIRD189) and EMD, we are starting to give meaning to the signal_name column, so we have to deal with it more rigorously. Walter said there are components that have two clk pins, one on each side of the component, that get routed to the chip from two sides but only go to one buffer on the Si. How do we want the model maker to represent that? EMD is a viable option, and we could force someone to make an EMD for that package. However, a component might have a redistribution layer (RDL) that connects multiple component pins to a single I/O buffer. Do we want to consider a change that would allow that to be handled within an .ibs file itself, as opposed to having to use EMD? This draft proposes one way to allow the .ibs file to handle the additional wire-bond pads to multiple pins on the component, and to then put the interconnect that connects them to one buffer inside the IBIS [Component]. The proposal states that all signal pins with the same signal_name shall have the same model name, and that all such pins shall connect to a single instance of that buffer model. Arpad said that we have to be very careful about the ways duplicate signal_names would interact with new IBIS Interconnect package models and legacy package modeling constructs. When we say such duplicate signal_name pins are "connected", at what interface? Walter agreed and said he'd specified rules depending on the package modeling type. For new style interconnect modeling, all such pins must appear as terminals in an interconnect model. For [Package], [Pin], and [Package Model]s that use [Number of sections] (i.e., uncoupled lumped and distributed elements) independent parallel paths are defined from each such pin to the single buffer. Walter noted that this proposal is not compatible with [Package Model]s using the coupled R, L, C matrices. Walter said that this may not be the way to go. It may be cleaner to make the model maker put this into an EMD similar to an interposer model. He said he was proposing it to see what others thought about trying to handle this RDL special case within the .ibs file. Jared asked for an explanation of EMD. Walter said that it is an enhanced version of EBD (electronic board description). EBD was originally designed for DIMMs. Instead of using a board file, it creates interconnects between the connector pins of the DIMM and the pins of the IBIS components. It was limited to lumped or distributed R, L, C paths, but the routing could be point-to-point or fly-by, etc. The Interconnect task is now working on EMD (electronic module description), which extends the concept to different substrates and packages and better interconnect models. So, now EMD could be used to represent the RDL's connections from the wire bump pads to the buffer pads. This new proposal might be an easier way to represent that RDL within the .ibs file. Arpad also recalled that EBD was originally conceived for DIMMs, which are small PCBs with multiple chips on them. The primary difference between EBD and the legacy IBIS package modeling was that it supported non one-to-one connections for signals between the external connector pins and the multiple chips. So, it doesn't matter whether it's a DIMM or a multi-chip module (MCM) or stacked die component. In an MCM the package is analogous to the DIMM PCB, and the chips are analogous to the components on the DIMM PCB. Jared said that his experience was in the die-side design, and his concern was that when the chip designer does the extraction they go all the way to the wire bond pad. He feared the RDL would already been included in the SPICE circuit used to generate the data in the IBIS [Model]. So, if we were to put RDL interconnect in an IBIS package model, he was worried about double counting. Randy said you have to consider whether the effect of that metal can be lumped into C_comp, or if you want to break it out as a transmission line model. This could give you the flexibility to do either. Walter said imagine you have a stacked die situation on a dense memory module. Maybe all the chips in the stack are identical, but each has a different RDL. It might be nice if the IBIS model considered everything up to the bump pad. Then you could put the individual chips in different [Component]s whose package models contain the RDL interconnect models. Randy said we had lots of flexibility now, for example, you could put the RDL in an interconnect model and handle the multi-die in an EMD. Bob said he thought we should defer this proposal for multiple pins with the same signal_names. He said it can get very complicated in certain areas, and some of Walter's new rules would have to appear in other sections. Arpad suggested that one way to simplify this would be to say that the new proposal is only available with newer interconnect syntax. Randy agreed. Bob said it's possible we can achieve this using only the new interconnect syntax. He noted, however, that one point of confusion would be the ambiguity of multiple pins connected to the same buffer instance. If two pins specify the same signal_name and model, how do you designate which buffer is connected? In interconnect syntax you'd have two buffers (conceptually), but only one would be connected? Arpad agreed that this could cause confusion, as a tool would look at the [Pin List] and assume each pin corresponded to a buffer. It wouldn't necessarily look at the interconnect model to see how the connections are made. Walter proposed a few possible variations, such as specifying an NA or NC model for the additional pins used in the interconnect model, so it was clear those pins couldn't be imported directly. Radek and Arpad thought this was questionable and confusing, and they suggested we might want to invent an RDL Pin keyword or a reserved Model name instead. Walter said he had just proposed the idea to gather suggestions and feedback. He said he would think about it some more. Walter moved to table the topic for now. Jared seconded. There were no objections. Supporting PI modeling/simulation in IBIS: Zhiping shared some thoughts from the IBIS Summit with the IEEE EMC+SIPI symposium. He said he thought some of the presentations contained good topics that could become BIRDs. He noted that a presentation from Intel on a standardized PI modeling concept even contained a rough draft of a BIRD. Randy suggested that it might be interesting to review the Intel presentation here in ATM. He asked if Michael could invite the presenter or possibly present it in ATM himself. Michael said he could look into it. Walter moved to cancel next week's scheduled meeting and pick up this topic at the following meeting. Randy seconded. There were no objections. There will be no meeting on September 8th. - Walter: Motion to adjourn. - Randy: Second. - Arpad: Thank you all for joining. ------------- Next meeting: 15 September 2020 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives